Secret 已經被讀走、資料已經送出、production 也部署完了，這時才出現在 dashboard 上的紅色警示，頂多是事故證據。它無法把任何一件事收回來。

不少團隊替 coding agent 接上完整 log，就以為有了安全控制。這個誤會不在於 log 不夠詳細，而是控制發生得太晚。只要 agent 能呼叫 shell、讀取憑證、連接 MCP 或操作部署工具，團隊就得先決定：哪些 tool call 可以做完再檢查，哪些必須在執行前停住。

先把三種控制拆開

同步閘門（synchronous gate）位在 tool call 前面。它根據 action、resource 與權限範圍直接允許、拒絕，或要求核准。未通過時，動作還沒有發生。

非同步監控（asynchronous monitor）在執行後或旁路分析行為。它很適合找異常模式、保留稽核證據，並把新風險回填到 policy。代價與延遲通常較低，也不會讓每個操作都卡在等待人類。

Code review 則是在驗收程式碼 artifact。Reviewer 看得到 diff，不一定看得到 agent 曾下載哪個 binary、向哪個 endpoint 傳資料，或在 setup 階段讀過哪些 credential。把 pull request 審查當成執行期安全控制，等於只驗收最後留下來的東西，卻忽略途中發生的副作用。

三者各自補不同的缺口，不能互相代班。

非同步 monitor 會進步，卻不會變成零漏失

英國 AI Security Institute 對 coding agent 非同步監控做過 red-team／blue-team 壓力測試。報告中的初版 monitor 最多漏掉 67% 的攻擊；經過反覆改善後，表現最好的版本在最差情境仍漏掉 6%。這是該評估環境的結果，不能直接當成所有 production agent 的失敗率。

這組結果也呈現了控制取捨：非同步監控可以降低成本與 latency，同步控制則能提供更強的即時保證。即使 monitor 持續改善，只要某項操作漏掉一次就可能造成不可逆結果，就不適合把安全性押在事後偵測上。

我會用四個欄位判斷閘門應該放在哪裡：

• reversible：失敗後能否可靠 rollback，而非理論上「應該救得回來」。
• exposure：是否接觸私有原始碼、個資、secret 或可延伸權限的 credential。
• external_side_effect：是否下載並執行陌生內容、對外傳輸、寄信、付款、merge 或 deploy。
• blast_radius：影響只留在 throwaway workspace，還是會碰到 shared repo、production 或跨 tenant 資源。

只要其中一項無法判斷又牽涉高權限，系統就先停下來，別用低風險的預設值處理未知操作。

把常見操作排成 action matrix

矩陣的目的不是把人類塞進每個 tool call。讀公開文件若也要等主管按鈕，團隊很快就會繞過整套機制。同步 gate 應該守住不可逆、會暴露資料或會影響外部系統的邊界，其餘操作交給 sandbox、限制條件與事後驗證。

Policy 要跟著 tool call 走

只在團隊文件寫「不得洩漏機密」沒有執行力。Runtime 收到 tool call 時，需要看得懂這次動作碰到什麼資源、會使用哪一段 credential，以及失敗後能不能撤回。

一個最小的 policy envelope 可以長這樣：

action: deploy
resource: production/web-frontend
credential_scope: deploy:production
external_side_effect: true
reversible: conditional
approval_required: true
requested_by: agent/session-8f21
artifact:
  commit: 4c9e8b1
  verification: ci/run-1842

Gate 不該只看 action: deploy。它還要確認 artifact 是否就是剛通過 CI 的 commit、credential scope 有沒有超出需要、rollback 條件是否存在，以及 approval 是否綁定同一份 artifact。否則人類核准的是 A，agent 最後執行的可能已經變成 B。

Gemini CLI v0.53 的 release notes 把 workspace trust、task isolation、A2A hardening 與 prompt-injection loop mitigation 列進 runtime。這些名稱本身不構成完整保證，卻指出正確的控制位置：信任判斷、隔離與阻擋都得進入 agent 執行工具的路徑，不能只留在事後報表。

同步擋風險，非同步修規則

同步 gate 只處理已知 policy，新的攻擊方式與奇怪使用路徑仍可能穿過分類。非同步 monitor 的工作，是從完整事件中找出這些漏網 pattern，再更新規則、測試案例與核准分級。

非同步監控還需要一份可信的 runtime inventory。企業裡實際運作的 AI 產品、tenant、agent 與 MCP connection，常比核准清單複雜。Island 公開的一個客戶案例中，環境裡出現 243 個活躍 AI 產品，而正式核准的工具只有 6 個。這是供應商提供的個案，不是通用統計，但它點出一個工程問題：monitor 若不知道有哪些連線與資料路徑存在，連「該觀察什麼」都答不出來。

我會保留兩條路徑：同步 gate 攔下不可接受的即時風險，非同步 monitor 整理未知行為，讓下一版 policy 少漏一些。兩者之間要有可追蹤的回饋流程，例如把未分類的高權限 action 轉成測試，再決定它能自動放行、需要條件式授權，或永遠拒絕。

Log 回答過去，閘門決定現在

Coding agent 的安全邊界不該由「我們之後查得到」來定義。公開唯讀操作可以順暢執行，可回滾修改可以靠隔離與驗證；碰到 secret、外傳、merge、刪除或 production side effect 時，系統必須在 tool call 送進 runtime 以前做出決定。

Log 很重要，它回答剛才發生了什麼。安全閘門負責另一個問題：這件事現在能不能做。順序放反了，再完整的事故紀錄也只是完整地告訴你哪一步沒攔住。

Source notes

• Stress-testing asynchronous monitoring of AI coding agents
• Gemini CLI release notes
• The AI You Can’t See: Why Shadow AI Is a Visibility Problem